Manifested here: https://github.com/IntersectMBO/ouroboros-consensus/actions/runs/21365715331/job/61496793074?pr=1841

Finally I know what is going on and it is quite convoluted:

• We have three handles in the forker registry (with theirs resource ID (rID for short)) A(2), B(4), C(5). They belong to these branches:

.. 565 -- -617 (A,2)
      \-- -617 (B,4) -- -611 (C,5)

• A(2) is there only because we forgot to close it.
• When transferring handles to the LedgerDB, we move the three of them, and they get new rIDs: A(2 -> 6), B(4 -> 7), C(5 -> 8), BUT we only update the rIDs known to the handles for B and C, so they think they are the previous resource
• This means
  • A is allocated at rID 6 and it is not made aware that it was transferred
  • B is allocated at rID 7 but it is told its new rID is instead 6
  • C is allocated at rID 8 but it is told its new rID is instead 7
• Then we select some fork that discards C, so we close it.
• Closing C will release resource 7 as that is the rID it thinks it belongs to. But that actually closes B.
• Then when we try to access B it will be closed, AND it will report in the exception that 6 was closed because that is what it thinks is its rID. It was 7 but it didn't know that.

So albeit the logic being quite complicated, the solution is in fact making sure that we close A when we discard that fork.